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Abstract 

Combining a set of existing constraint solvers into an integrated system of cooperating 
solvers is a useful and economic principle to solve hybrid constraint problems. In this paper 
we show that this approach can also be used to integrate different language paradigms 
into a unified framework. Furthermore, we study the syntactic, semantic and operational 
impacts of this idea for the amalgamation of declarative and constraint programming. To 
appear in Theory and Practice of Logic Programming (TPLP). 
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1 Introduction 

Declarative programming languages base on the idea that programs should be as 
close as possible to the problem specification and domain. In particular, the se- 
mantics of the computation does not depend on the concepts of time and state. 
Programs of these languages usually consist of directly formulated mathematical 
objects, i.e. of predicates and functions in logic and functional (logic) languages 
resp. which are used to describe properties of problems and required solutions. 

Our point of view is to consider declarative programming as constraint program- 
ming: Syntactically this is evident. Logic languages are based on predicates, and 
goals (on these predicates) are constraints. For functional languages the under- 
lying equality relations can be regarded as constraints as well. But this point of 
view also applies to the (operational) semantics: the evaluation of expressions in 
logic and functional languages consists of their stepwise transformation to a normal 
form, while particular knowledge is collected (in the form of substitutions). This 
corresponds to a stepwise propagation of constraints. 

This kind of consideration opens an interesting potential: In l|Hofstedt 2fl0flb(l 
a framework for cooperating constraint solvers has been introduced which allows 
the integration of arbitrary solvers and the handling of hybrid constraints. Con- 
sidering declarative programming as constraint programming and looking at the 
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language evaluation mechanisms as constraint solvers we are able to integrate these 
solvers into this framework. Within the framework it is then possible to extend the 
declarative languages by constraint systems and, thus, to build constraint languages 
customised for a given set of requirements for a comfortable modelling and solving 
of many problems. The paper elaborates this approach. 

We start with a recapitulation of necessary concepts and elements of the syn- 
tax and semantics of declarative languages in Sect. |21 Section 13 reintroduces the 
framework for cooperating solvers of 'Hofstedt (2000b I. In Sect. 0] we examine the 
integration of a functional logic language and consider the approach w.r.t. a logic 
language. We conclude our paper with a discussion of the gains and perspectives of 
the approach in Sect. Inland compare it with related work. 



2 Declarative Programming Languages 

Declarative languages are roughly distinguished into functional, logic, and con- 
straint programming languages. 

All declarative languages base on the concepts of signatures and terms. 

Definition 2.1. A signature S = {S, F, R) consists of a set 5* of sorts, a set F of 
S'-sorted function symbols and a set R of ^-sorted predicate symbols. R contains 
in particular equality symbols for every sort s £ S and the predicate symbols true 
and false. 

By T{F, X) we denote the usual set of free F-terms, short: terms, over the set 
X of S'-sorted variables. Variable-free terms are called ground terms. Expressions 
r(ti, . . . ,tn) with terms ti and a predicate symbol r € i? as outermost symbol are 
called predicate terms. By T(S, X) we denote the set of terms and predicate terms. 

Given a "E-structure V we obtain the usual notions of the value of a ground term 
t in V and of the validity of a predicate term p in V, denoted as I? N p. < 

In connection with the evaluation of programs the well-known notions of substi- 
tutions and unifiers play a central role. We briefly recall their main aspects. 

Definition 2.2. By t[t'] we denote a term t with a distinguished subterm t' . (This 
can be formally defined using either positions or contexts.) 

A substitution cr is a sort-preserving association {xi = ti, . . . = tm} from 
variables Xi £ X to terms ti £ T{F,X). (Since it fits more nicely into our overall 
framework and therefore simplifies some of the later presentations, we write substi- 
tutions here as special equations.) The application of a substitution cr to a term or 
predicate term e is denoted as cr{e). 

A unifier of two terms or predicate terms t and t' is a substitution cr which makes 
them equal: crit) — cr(t'). The most general unifier is denoted as mgu{t,t'). 

The composition of some substitutions a and 4> is defined by {ao(j)){x) — a{<j){x)) 
for all X £ X. K substitution a is idempotent, li a o a = a holds. 

The parallel composition "f of idempotent substitutions is defined as in IjPalamidessi 199(l| , 
i.e. {a ] (j)) = mgu{a, (j)). (Since we consider substitutions as special equations, mgu 
is defined for them.) <\ 



Integration of Declarative and Constraint Programming 



3 



Starting from the foundation T(E, X) we build a hierarchy of language paradigms. 



constraint functional (logic) 




functional logic constraint logic 




r(s,x) 



In the following we briefly sketch the syntax and the underlying ideas of this 
hierarchy. In the subsequent sections we will then address the much more important 
issues of the semantic and operational integration of the different paradigms. 

Functional programming. The realm of functional programming languages (ex- 
amples are haskell IjHudak et al. 2000|l and opal IjPidrich et al. 1994|l 1 is inhab- 
ited by a plethora of syntactic variations. For our conceptual treatment we can 
constrain this to a minimal core that is as close as possible to the other kinds of 
languages that we are treating here. In the following, we distinguish two (disjoint) 
subsets of the set F of function symbols of the signature E: the set A C F of 
constructors of the underlying data types and the set $ C i<" of defined functions. 

Definition 2.3. A functional program P over S is given by a finite set of rules of 
the form (called pattern-based definitions) 
/(ti, . . . , tn) t 

where / G is a defined function and the parameter terms ti g T{A, X) are linear 
constructor terms, i. e. are built up from constructors and variables such that every 
variable occurs only once. The right-hand side t e T(_F, X') is an arbitrary i^-term, 
restricted to those variables X' C X that actually occur on the left-hand side. < 

The evaluation of a functional program P reduces a given ground term e using the 
rules of P until a normal form is obtained IjField and Harrison 1988)l . Each reduc- 
tion step picks some function call f{e[, . . . , e^), that is, a subterm oie[f{e[, . . . , eJJ], 
which can be unified with the left-hand side of some rule /(ti, . . . ,t„) — s- t. The 
resulting unifier a = mgu(f(ti, . . . ,tn), /(e^, . . . , eJJ) is then applied to the right- 
hand side t to derive the new term e[cr(f)]. 

Since there may be different applicable rules for a chosen subterm caused by 
overlapping left-hand sides, the rule selection strategy - e. g. first-fit or best-fit ~ of 
the language ensures a deterministic rule choice. 

Moreover, there are different reduction strategies for picking a redex in each 
step, for example leftmost-innermost, leftmost-outermost, lazy, etc. These strate- 
gies lead to quite different semantics as has already been studied extensively in 
l|Manna 1974|l . These differences are mainly reflected in the model-theoretic in- 
terpretation of the equality ti = of the functional domain. For the following 
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illustrating examples an intuitive understanding of equality will do. A thorough 
elaboration will be given in Sect. 01 

Example 2.1. The following functional program provides rules for the addition of 
natural numbers which are represented by the constructors and s. 

add(0,X) (1) 
add(s(X) ,Y) ^ s(add(X,Y)) (2) 

This leads e.g. to the following evaluation sequence, where the reduced subterms 
are underlined: 

add(s(0),s(s(0))) -^(2) s( add(0,s(s(0))) ) -^(i) s(s(s(0))) <] 

Since we will use it later on, we present a second example here. It comes from 
the realm of resistors and their composition. 

Example 2.2. For describing the composition of resistors wc have three constructor 
functions: a simple resistor, sequential composition, and parallel composition. The 
laws of physics entail the program rules: 

rc(simple(X)) X 
rc(seq(Rl,R2)) rc(Rl) + rc(R2) 
rc(par(Rl,R2)) l/(l/rc(Rl) + l/rc(R2)) 

This allows e. g. the following evaluation: 

rc(par(simple(300), simple(600))) l/(l/rc(simple(300))+l/rc(simple(600))) 
--^ 1/(1/300+ 1/600)^ 200 < 

Functional logic programming. Functional logic programming was originally 
developed as an extension of functional languages by concepts of logic languages, cf. 
HReddy 1985||Loogen 1995| ). However, they can as well be considered as embedding 
functional concepts into a logic language, which is indicated by the dashed connec- 
tion in the above diagram. Typical representatives are babel ( |Moreno-Navarro and Rodriguez- Artalejo 1992| 
and CURRY IjHanus et al. 2003|l . 

Syntactically, a functional logic program looks like a functional program. The 
difference lies in the evaluation mechanism. Whereas functional programs only allow 
the reduction of ground terms to normal forms, functional logic programs also allow 
the solving of equations using residuation l|Ait-Kaci and Nasr 198911 and narrowing 
IIHa,Tius 1994|l. 

A narrowing step is a transition e[l'] -^i^r^a "'(eH); where I ^ r is a rule from 
the program P and /' is a non-variable term (i. e. /' ^ X) such that a ~ mgu{l', I). 

Example 2.3. We again use the above addition example. In order to solve the 
equation add(s(A),B) = s(s(0)), we apply narrowing. The chosen subtcrm is un- 
derlined. 

add(s(A) ,B) = s(s(0)) ^(2),{xi=aji=b} s( add(A,B) ) = s(s(0)) 
'^(i),{A=o,x2=B} s(B) = s(s(0)) 

Thus, a solution of the initial equation is given by the substitution (t(A) = and 
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cr(B) = s(0) which is computed by unification of s(B) and s(s(0)) after the last 
narrowing step. < 

We need to ensure confluence of the rewrite system which is essential for complete- 
ness. Thus, the rules of functional logic programs usually must satisfy particular 
conditions, e. g. linearity of the left-hand sides, no free variables in the right-hand 
sides and (weak) nonambiguity for lazy languages, cf. IjHanus 1994|l . 

An overview of functional logic programming languages is given in IjHanus 1994|l . 
where the following assessment is made: "In comparison with pure functional lan- 
guages, functional logic languages have more expressive power due to the availability 
of features like function inversion, partial data structures, and logic variables. In 
comparison with pure logic languages, functional logic languages have a more ef- 
ficient operational behaviour since functions allow more deterministic evaluations 
than predicates." 

It should not come as a surprise that the aforementioned semantic intricacies of 
functional languages carry over to functional logic programming, leading to notions 
such as innermost narrowing and the like, cf. IjHanus 1994|l . But there are more 
severe problems, which are often ignored in the literature. Consider the example 
from l|Hanus 1994|l . 

Example 2.4. Consider the following program 

f (X) ^ a 
g(a) ^ a 

For the equation f (g(X)) = a innermost narrowing yields the substitution {X = a} as 
the only solution, whereas outermost narrowing provides the identity substitution 
{} as solution. However, this depends on the language semantics. In most functional 
languages the function g would be considered undefined for all arguments but a 
(since there are no patterns for the other cases). And in a call-by- value semantics 
this would entail that {X = a} is the only solution. This illustrates that call-by-name 
or call- by- need semantics is incompatible with innermost strategies pvlanna 193)). 
These observations will play a role in our later considerations in Sect.01 <] 

Logic programming. By contrast to functional programming, logic programming 
is based on predicate terms. 

Definition 2.4. A logic program P is a set of rules of the form 

9o(*0,l' ■ ■ ■ ' ^0,m) :~ 91(^1,17 tl,n), ■ ■ ■ ,qk{tk,l, ■ ■ ■ ,tk,r), fc > 0. 

where the qi{. . .) are predicate terms and they are called atoms. The borderline 
case fc = 0, which has no conditions, is called a fact. <] 

The evaluation of a logic program is based on resolution. One starts with a goal 
{Ri A ... A i?;), which is a conjunction of atoms, and adds its negation {^Ri V ... V 
-^Ri) to the set of rules. Then one has to find a refutation, that is, a sequence of 
resolution steps which ends with the empty clause □. 

A resolution step on a goal G = {R[ A ... A R'^) E^nd a program P takes one 
subgoal i?- and a new variant r — {Q : — Qi, . . . , Qn-), n > 0, of a rule of P 
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such that R[ and Q can be unified with most general unifier a. The result of the 
resolution step G ^a,r G' is the new goal G' = {cr{R[) A ... A a{R^_i) A ct(Qi) A 
. . . A a{Qn) A A ... A <jiR'^)). 

If a refutation can be computed, i.e. P \= 3{Ri A ... A Ri) holds, then the com- 
putation yields an answer substitution (p (as composition of the unifiers computed 
in the resolution steps) such that P N V (f){Ri A ... A i?;) holds. For a detailed 
description of logic programming and its well-known representative PROLOG see for 
example ( |Nilsson and Maluszyhski 1995| ). 

Constraint programming. Here problems are specified by means of constraints, 
that is, first order formulas which express conditions or restrictions describing prop- 
erties of objects and relations between them. Constraints come from constraint 
systems: 

Definition 2.5. Let S — {S,F,R) be a signature such that R contains at least a 
predicate symbol for every sort s ^ S. Let X be a set of E-variables. Let I? be a 
E-structure with equality, i. e. for every predicate symbol there is an according 
predicate which is an equivalence relation and fulfils the following requirements: 

For ail f G F, r £ R and all terms ti,t'^ £ T{F, X) of appropriate sorts Sii 
If for all i:V\= y{t, t'^, then 

. V N V(/(ti, . . . , i„) =^ f{t[, . . . , 4)), when f{t,, . . . , t„) and f{t[, 

both defined, or both terms are undefined, 
• P 1= V(r(ti, ...,tjn)^ r{t[, . . . when r{ti, . . . ,t„) and r{t[, 

both defined, or both terms are undefined. 

A basic constraint is of the form r{ti, . . . , t^), where r G R and ti S T{F, X). 
The set of basic constraints over E is denoted by Constraint. It contains the two 
distinct constraints true and false with V N true and V false. 

A constraint system is a 4-tuple C = (E, P, X,Cons), where {true, false} C 
Cons C Constraint. <l 

Example 2.5. A typical example are constraint systems for linear arithmetic with 
constraints that are equalities and inequalities, e.g. X-|-2*Y = 7 and X < 3.5. 

In this realm the signature E usually contains the function symbols and 
the relation symbols =,>,<. <l 

The evaluation of constraints is handled by constraint solvers. These are so- 
phisticated algorithms for particular application domains, for example the simplex 
algorithm for linear arithmetic. Constraint solvers can not only check the satisfia- 
bility of constraints but can also compute entailed constraints, projections and even 
solutions. A solution of a constraint is a valuation which satisfies it. 

In order to allow more convenient programming, constraint systems can be em- 
bedded into an appropriate language, which provides concepts like recursion, en- 
capsulation and abstraction. This leads to constraint logic and constraint functional 
(logic) programming. 



...,t'J are 
. . . , 4) are 
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Constraint logic programming. Logic programs are extended by constraints 
such that the right-hand side of a rule may not only contain atoms but also con- 
straints from an arbitrary constraint system. Consequently, the evaluation mech- 
anism of logic languages, viz. resolution, has to be extended by mechanisms for 
collecting constraints and checking their satisfiability using appropriate constraint 
solvers HJaffar et al. 1 998). 

The first and also the most typical language which has been extended by con- 
straints, was the logic programming language PROLOG; the initial motivation was 
to overcome the limitations of the expressive power of the language when reasoning 
about arithmetic. A typical and comfortable constraint logic programming system 
is ECL^PS^ (ICheadle et al. 20m. 

Constraint functional (logic ) programming. Functional (logic) languages can 
be extended further by guarding the rules with sets of constraints. 

Definition 2.6. A constraint functional (logic) program P over E is given by a 
finite set of rules of the form 

/(ii, ...,tn)^t where G 
where - as in functional logic programs - f G ^, ti E T{A,X) and t £ T{F,X). 
But now we have in addition a set G of (basic) constraints over S and X. < 

For example, toy(J^X') (jFernandez et al. 2003}! and toy{TZ) (jHortala-Gonzalez et al. 1997)1 
allow finite domain constraints and real arithmetic constraints, resp. 

An example of a constraint functional logic program and its evaluation will be 
considered informally in Sect. 13. ll The evaluation mechanism is discussed in detail 
and formally in Sect. 01 

3 Cooperating Constraint Solvers 

The basic architecture of a simple constraint solving system is a solver algorithm 
CS associated to a constraint store G and a constraint pool] both are sets of (basic) 
constraints (see Figure ^(a))- 

• Initially the constraint store of a solver is empty, more precisely: it contains 
only the constraint true; the constraint pool contains the constraints to solve. 

• By the so-called constraint propagation the solver adds constraints from the 
pool to its store while ensuring that the constraints in the store remain sat- 
isfiable. In this way the set of possible valuations for the variables of the 
constraint store is successively narrowed. 

• If the solver detects an inconsistency, the corresponding constraint is rejected. 

When constraints from different realms shall be used together, one has two pos- 
sibilities. Either one programs a new solver that is capable of handling all kinds 
of constraints. Or one takes several existing solvers, one for each realm, and coor- 
dinates them by some mediating program. The former approach usually generates 
more efficient solvers, but the amount of implementation work becomes prohibitive, 
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Fig. 1. General architecture for (cooperating) constraint solvers 

when more and more kinds of constraints shall be integrated. Therefore we focus 
on the second approach, which is more flexible and more economic. 

In IjHofsted t 2000a) a framework for cooperating constraint solvers has been in- 
troduced and formally described, including cooperation strategies for the solvers. In 
l|Hofstedt 2001|l termination and confluence, as well as soundness and completeness 
restrictions are examined. An implementation of our system meta-S is described in 
(|Fra,Tik et a,l. 2008allFrauk et aJ. 2nn8bt. 

Figure n](b) shows the architecture of our system for cooperating solvers. In the 
following let L with /i, i/ G L denote the set of indices of constraint systems. 

• The stores of the individual constraint solvers CSi, hold the constraints 
which have been propagated so far. Initially they are all empty. 

• The constraint pool is again the set of constraints that still need to be con- 
sidered. Initially it contains the whole constraint problem to be solved. 

• The meta solver coordinates the work of the individual solvers. It distributes 
the constraints from the pool to the appropriate solvers, which put them 
into their stores by constraint propagation and use them for their local com- 
putation (see the function tell,y below). Conversely, constraints in the local 
stores may be projected to the pool in order to make them available as new 
information to other solvers (see the functions proj^^^^ below). 

The process of sequent propagations and projections ends, when no more informa- 
tion exchange takes place. Then the contents of the stores and of the pool together 
represent the result: it may indicate, whether the initial constraint conjunction was 
unsatisfiable or not; moreover, restrictions of the solution space are provided by 
means of projections of the stores. The restrictions may even provide a full solution 
of the problem. 

Details of the cooperation and communication of the involved solvers are deter- 
mined by the cooperation strategy of the solvers. A cooperation strategy may influ- 
ence the solution process with regard to different criteria. The solver cooperation 
system META-S which implements our ideas provides a flexible strategy definition 
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framework. One can prescribe particular search strategies, one can formulate choice 
heuristics for constraints with respect to their gestalt and their domains, one can 
specify the order of propagation and projection and so forth. For this system it 
has been shown in IjFrank et al. 2003a|l that appropriate strategies for solver co- 
operation can yield comfortable performance improvements for various kinds of 
constraint problems. 

At the heart of our approach are the requirements for the interfaces by which the 
solvers are integrated into the system. There are essentially two kinds of operations 
that constitute this interface (cf. Sect. 13.21 and 13. 3|) : 

• For every solver CSi, there is a function tellu for propagating constraints from 
the pool to the store C^. 

• For every pair of solvers CS^, CSf^ there is a function proj for providing 
information from the store Ci, to the solver CS^ (via the constraint pool). 
Note that this entails the translation into the other solver's signature. 

3.1 An Example 

To give a better intuition about the working of our approach, we present a small 
example. It is taken from the realm of constraint functional logic programming and 
illustrates the interaction of a functional logic language with a finite domain solver 
and a solver for interval arithmetic. 

Example 3.1. The following program^ describes resistors from a certain set {300 Vl, 
. . . , 300017}, as well as the formulas for the sequential and parallel composition 
of resistors. The formulation is a mixture of functional logic programming and 
constraint programming. The first constraint uses the membership test g jF-p from a 
constraint system for finite domains, and the other two constraints use the equality 
=j( from a constraint system over rational arithmetic. The equality —j^c comes 
from the functional logic resolution mechanism. 

rc(simple(X)) X where X e^p {300, 600, 900, 1200, . . . , 2700, 3000} 
rc(seq(Rl,R2)) ^ Z where X + Y =^ Z, X =;r£ rc(Rl), Y=^£rc(R2) 
rc(par(Rl,R2)) ^ Z where 1/X + 1/Y =^ 1/Z, X =;r£ rc(Rl), Y ==jr£ rc(R2) 

Note that the various subterms (including equations) in this program are all 
homogeneous, that is, they are in T(S, X) for the signature of one of the underlying 
solvers. This is possible in general: by introducing auxiliary variables we can always 
turn hybrid terms into homogeneous terms; this is called flattening of terms and 
constraints, resp. Again, this relies on an appropriate semantic definition of the 
functional logic equality =jc-£ (which will be discussed in Sect.0}. 

In the following we sketch the way, in which our approach may handle the above 
program. For the time being, the treatment is on a more intuitive basis. The for- 
malisation of the various steps will be given subsequently. We use the following 

^ We use so-called extra variables in the rules, i. e. variables which occur in the body but not in 
the head. We discuss the issue of completeness in presence of extra variables briefly in Sect. 14. ll 
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notation to illustrate the snapshots from the evahiation, where the three stores 
Cyr£^, Cj:t> and belong to the functional logic language solver, the finite domain 
solver, and the arithmetic solver, resp. 



C onstraintPool 


store of CSj^c 


store of CSj^T) 


store of CS^ 



(1) Suppose we want to compose two resistors in parallel and need a combined resis- 
tance of 200 O. The question is, which resistors do we have to pick from our set. This 
question is formalizable in our program as the equation rc(par(RA, RB)) =j^c 200. 
This leads to the following initial configuration. 





rc(par(RA, RB)) 


=^C 200 


true 


true 


true 


(2) We apply the third rule (using narrowing^ 


and reach the following system state. 


Z =:fc 200, 1/X + 1/Y =A 1/Z, X 




rc(RA), Y rc(RB) 


true 


true 




true 



(3) When there are several constraints in the pool, the particular cooperation strat- 
egy of the system decides, which constraint to choose next for propagation, here 
e.g. the goal 1/X+ 1/Y =^ 1/Z. We propagate it (using the function tellj\) to the 
arithmetic solver (75^. This is followed by a propagation of Z =j^c 200 to the store 
of CSj^c- (In the pertinent stores we can omit the index of the equality symbol.) 

X =^c rc(RA), Y =^c rc(RB) 



Z = 200 



true 



1/X+1/Y= 1/Z 



(4) Next, the system chooses the goal X =j:c rc(RA) for a narrowing step based on 
the rules of our program (using the function tellj^c)- This leads to a disjunction of 
three possibilities: 

RA =^£ siniple(X) A X e^p {300, 600, . . . , 3000} 

V RA =:f£ seq(Rl, R2) A (Xi + Yi =a X) A Xi rc(Rl) A Yi rc(R2) 

V RA par(Rl,R2) A (I/X2 + I/Y2 =a 1/X) A X2 =rc rc(Rl) A Y2 =rc rc(R2) 

Due to the disjunction, we have to form three instances of our configuration, each 
representing one of the choices. For lack of space we only present the derivation of 
the first alternative here. 

RA =3^c simple(X), X Sjfp {300, . . . , 3000}, Y =:f£ rc(RB) 



Z = 200 



true 



1/X -I- 1/Y = 1/Z 



Note that the store C^f^ did not change in this step. The application of a program 
rule causes a replacement of the chosen constraint by new ones according to the 
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right-hand side of the rule. In contrast, an enhancement of the store happens at the 
propagation of constraints which do not contain defined functions any more, as we 
will see in Step (6). 



(5) Now we apply the same process to the second goal X =rL rc(RB), again pursuing 
only the first variant. 



=jr[^ simple(X),X G 


T-D {300, ...},RB=;P£ simple(Y),Y e^p {300, 3000} 


Z = 200 


true 


1/X+ 1/Y== 1/Z 


(6) Next we propagate all the constraints of the pool to their associated stores. 


true 


RA = simple(X) 
RB = simple(Y) 
Z = 200 


X e {300, . . . , 3000} 
Y e {300, . . . , 3000} 


1/X+ 1/Y= 1/Z 



(7) At this point a system without solver cooperation would terminate the compu- 
tation and not draw any further conclusions. 

But our system enables solver cooperation. For the continuation of our example 
we assume that the cooperation strategy of the system now forces the finite domain 
solver to project its store by generating bounds for the variables using the function 
proj ■pD^j^.'^ This is followed by a projection of Cj^c for the variable Z common to 
Cjr£ and Cj(. 



(Z =A 200), 


(300 


<^X), (X<^ 


3000), (300 <yiY), 




3000) 


RA = simple(X) 
RB = simple(Y) 
Z = 200 


X e {300, . . . 
Y e {300, . . . 


, 3000} 
, 3000} 


l/x^ 


-1/Y = 


1/Z 



(8) The new constraints in the pool are now amenable to treatment by the arith- 
metic solver. Therefore the meta solver propagates them (using tell a) to this solver. 
Using its computational capabilities, the arithmetic solver can derive more accurate 
bounds: 



true 


RA 


= simple(X) 


X e {300, 


. . , 3000} 


1/X+ 1/Y 


= 1/200, Z = 200 


RB 


= simple(Y) 


Y e {300, 


. . , 3000} 


(300 < X), 


(X < 600) 


Z = 


= 200 






(300 < Y), 


(Y < 600) 



^ Actually, our implementation META-S IFrank et al. 2003ai distinguishes between weak projec- 
tion generating only constraint conjunctio ns and stro ng projection which is allowed to project 
disjunctions as well (first proposed in (Hof stedt 20011 ). Usin g different kinds of projections we 
are able to realise a variant of the Andorra principle ICost a ct al. 1991 Warren 19^} which 
proved to be very advantageous w. r. t. efficiency. The generation of bounds in our example 
represents a weak projection. 
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(9) In the following steps the arithmetic solver's improved bounds can be projected 
back to the pool, from where they are propagated to the finite domain solver, which 
then narrows down its choices. 



true 


RA — simple(X) 


X e {300,600} 


1/X+ 1/Y 


= 1/200, Z = 200 


RB = simple(Y) 


Y e {300,600} 


(300 < X), 


(X < 600) 


Z = 200 




(300 < Y), 


(Y < 600) 



(10) At this point we need strong projection (cf. footnote |(5J)) by which the finite 
domain solver puts a disjunction of equations 

(X =A 300 A Y =^ 300) V ... V (X =^ 600 A Y =^ 600) 
into the pool. Each of these four conjunctions can again be propagated to the 
arithmetic solver. Two of them will lead to solutions, but the other two propagations 
lead to inconsistencies in the arithmetic solver and are therefore discarded. One 
successful final configuration is: 



true 


RA = simple(300) 


X = 300 


Z = 200 


RB = simple(600) 


Y = 600 


X = 300 


Z = 200 




Y = 600 



The solution {RA = simple(300), RB = simple(600)} can be extracted from the 
constraint store Cjr£ of the solver CSjr^. <] 

This small example already demonstrates the important role of cooperation 
strategies for the efficiency of the computation. For example, the ability to con- 
trol the order of weak and strong projections allows a considerable restriction of 
the set of variable assignments before an explicit search for solutions is initiated for 
the remaining alternatives. Suppose that we had applied the strong projection at an 
earlier point. This would have caused a search across all 100 alternatives of resistor 
combinations, i.e. (X =a 300 AY =a 300), . . . , (X =^ 3000 AY =a 3000). As a mat- 
ter of fact, it is in general a good strategy to delay the introduction of disjunctions 
as long as possible for the sake of efficiency. This is suggested by experiences with 
the KIDS system JWestfold and Smith 200T)l . 

Based on the intuitive insights provided by this example we will now look more 
deeply into the precise definitions of the propagation function telli, and the projec- 
tion function proj 

3.2 Constraint Propagation (tell^) 

As can be seen e.g. in Step (3) of the above example, the function tell^, v € L, 
takes a constraint c S ConSi, (i. e. a basic constraint of the constraint system of 
solver CSy) from the pool and adds it to the constraint store C^, which leads to a 
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tellv- Consu X Storey — > {true, false} x Stores x 'DCConsv with 

1. if tell^{c,C„) = {true,Cl,c"), then 

(a) O,. N V((a A c) ^ id A c")), 

(b) D,. N V(C:, — ^ C), 

(c) V,, N 3C:„ 

2. if tell^{c,C^) = {false,Cl,c"), then 

= c" = false, N ^3(C, A c). 

Fig. 2. Interface function tell^, v Cz L, (requirements) 

new store C^. There may also be a remaining part c" of c, which is put back into 
the pool (but this happens rarely in practice). 

Example 3.2. Suppose we have the constraint \/x = Y in the pool. This may be 
used to put the constraint X = into the store of some solver, while keeping the 
constraint Y > in the pool. <] 

Figure 121 shows the requirements for the function tell,y.^ The function returns 
three values. The first one is a Boolean indicator of the success or failure. The 
second one is the modified store. And the third one is the remaining constraint 
c" G DCConSu, which is put back into the pool. By VCConSi, we denote the set of 
disjunctions of constraint conjunctions. 

When the solver successfully propagates a constraint c to a store Ci, (Case^, 
then it must be ensured that the (overall) knowledge of the store and the constraint 
is neither lost nor increased (a). It is only possible to add constraints to a store, 
but not to delete them. Thus, the new constraint store must imply the old one 
(b). Of course, the new store CI has to be satisfiable in the domain Vi, of CSi, as it 
is a constraint store (c). In Example 13. II e.g. in Steps (3) and (4), tellA and telljr^ 
have been applied according to this definition. 

This first case also covers the situation that a solver is not able to handle a 
certain constraint c, i. e. if the solver is incomplete. In this case the store Ci, does 
not change and c — c" remains in the pool.'* 

Figure |21 visualises the state change of the system when a solver performs a 
successful constraint propagation. The left side shows the system before the prop- 
agation, the right side afterwards. When we propagate c to by tell^{c,Cv), c 
is deleted from the pool and propagated to the store C^. The resulting new store 
CI and the remaining constraint c" may in general be disjunctions of constraint 
conjunctions, e.g. c" — Vie{i n} Since store and pool are sets of basic con- 
straints, this causes a splitting of the system as shown in Figure 13 

^ In IHof'stedt 2000a^ two forms of successful propagation are distinguished, which is necessary 
for general solvers to ensure termination of the system. For the "language solvers" considered 
in this paper this is simplified. 

Again, to ensure termination of the overall system, this particular case must be detected by 
the overall machinery and the treatment of the constraint must be suspended. We omit this 
technical detail in favour of readability. 
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tell{c,Cu) = {true,Cl,c"), 
where c £ Consv and c" = ViG{i 



^ 

MCS 

CS„ ... CSj, 



MCS 



cs„ ... cs„ 



Fig. 3. Application of the interface function tell 



If tell^{c,C,y) fails (Case because c and Ci, are contradictory, then false is 
added to the constraint pool and Ci, does not change (not shown in Figure |2J). 

Example 3.3. The interface function tellA of our rational arithmetic solver CSa 
could work as follows (see e.g. Step (10) in Example 13. 1(1 : 

Given the store C = (1/X+l/Y =a 1/200) the propagation tellA{{^ ^a 300), C) = 
{true, C", true) yields - after some computation by the solver CSa ~ a new simpli- 
fied store C" = (X =A 300 A Y =^ 600). On the other hand, tellA{{^ >a 600), C") = 
(false, C , false) represents a failing propagation. < 

For each concrete solver CSi, the user must provide a suitable function tell^. 
However, constraint propagation is mainly based on the satisfiability test which is 
the main operation of a constraint solver. Moreover, the requirements in Figure El 
are chosen in such a way that they allow an easy integration of many existing 
solvers into the cooperating system, taking particular properties of solvers (like 
their incompleteness (cf. Case^ or an existing entailment test) into consideration. 

Examples for such concrete propagation functions will be shown in Sect. 0] for 
the special cases of functional logic and logic languages, when they are viewed as 
solvers. 



3.3 Projection of Constraint Stores (proj^,^^) 

Projection is used for information exchange between constraint solvers CSi^ and 
CS^, v ^ fi, fi, v € L, via the constraint pool. 

Figure^shows the requirements for the function proj^^^. The function proj^^^ 
takes a set of common variables of the two solvers and the local store C,^ and returns 
(a disjunction of conjunctions of) constraints to the pool, proj ^^^{X,Cy) — c 
describes a projection of a store Ci, w. r.t. common variables (i.e. X C n X^) 
to provide constraints c of another solver CSfj,. It provides knowledge implied by 
the store C^. Projection does not change the stores but only extends the pool by 
the projected constraints. 

To ensure that finally no solution is lost, a projection c must provide every 
satisfying valuation of the current store C^. That is, proj^^^ must be defined 
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proj^^^ : p(Xv n X^) X Storev — > T>CConSf_i, where 'Vars{proj^^^{X, Cu)) = Y X, 
must be sound, i. e. for every valuation cr^ for the variables of Y must hold: 
If {V^,(Jv) N 3.yCv, then (7?^,(j^) N proj\,_^^(X, C^), where 

3_yC^ denotes the existential closure of formula d, except for the variables of Y . 
Fig. 4. Interface function proj,^^^, ii ^ v, jji^v ^ L, (requirements) 

in such a way that every solution ct^ of Cj/ is a solution of its projection c in 
(soundness). 

Example 3.4. Consider the arithmetic solver CSji, and the finite domain solver 
CSrv- Let Cjf© = (X e^p {300, . . . , 3000} A Y e^rr, {300, . . . , 3000}) hold. Define 
proj jr-p^ji^ (as a weak projection, cf. footnote Q) such that 

Proj^27^^({x}, C^c) = ((X >x 300) A (X <A 3000)). 
This corresponds to Step (7) of Example 13. II < 

As in the case of telln the function proj^^^ has to be concretely programmed for 
every pair of given solvers. For many pairs of solvers it is possible to automatically 
provide simple projection functions generating equality constraints which at least 
express variable bindings. Often it is also sufficient to provide actual projection 
functions only for particular pairs of solvers and to reduce superfluous communica- 
tion. 

Examples of projection functions will also be shown in Sect.0]in connection with 
constraint functional logic and constraint logic languages. 



3.4 Semantics 

In (|Hofstedt 2001|l we define reduction systems describing solver collaborations 
based on the interface functions tell^ and proj The reduction systems work on 
so-called configurations which consist of representations of the current constraint 
pool and the associated stores, which together represent the state of the system. 



Hofstedt (2001 1 gives a detailed discussion of the termination, confluence, sound- 



ness and completeness of the reduction systems. 

Based on the signatures and E-structures of the incorporated constraint systems 
we build combined constraint systems by their disjoint unions. Clearly, for those 
sorts and function and predicate symbols that are common to different systems the 
corresponding carrier sets, functions and predicates must be identical. This applies 
in particular to the semantics of the equality symbol (on shared sorts). 

It is shown that - using our method - no solutions are lost. If the system fails 
then the given constraint problem is unsatisfiable. Furthermore, we discuss the 
situation of suspended constraints remaining in the pool due to the incompleteness 
of solvers. If all incorporated solvers are complete and the reduction relation is 
terminating, then for a satisfiable constraint problem the method can be guaranteed 
to be successful. 
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The soundness and completeness results do not depend on the particular coop- 
eration strategy of the solvers. 

The (obvious) fact that the completeness of the overall system depends on the 
completeness of the individual solvers will play a role in connection with functional 
logic languages. 

4 Combination of Declarative and Constraint Programming 

As a particular application, our system of cooperating solvers allows the integration 
of different host languages by treating them as constraint solvers. As a matter of 
fact, it even makes it possible to work quite flexibly with different evaluation strate- 
gies, that is, different operational semantics. A good point in case are functional 
(logic) languages, which have very different semantics depending on the chosen 
evaluation mechanisms. As mentioned in Sect. 13 this has already been elaborated 
in the textbook UManna 1974|l for functional languages; for the realm of functional 
logic programming the pertinent issues are described in IjHanus 19941 IHanus 1995)l . 

The feasibility of this idea is based on two main observations: First, the evaluation 
of expressions in declarative languages consists of their stepwise transformation to 
a normal form while particular knowledge (in the form of substitutions) is collected. 
Second, this way of proceeding is similar to a stepwise propagation of constraints 
to a store, which is simplified in doing so. 

In the following, we consider the integration of a functional logic language and 
of a logic language, resp., into the system of cooperating solvers. Syntactically, we 
extend the languages by constraints, but their evaluation mechanisms are nearly 
unchanged: they are only extended by a mechanism for collecting constraints of the 
other constraint solvers. 

A four-step process. The integration of a declarative language into our system 
of cooperating solvers requires four activities. 

1. The inherent constraints of the language have to be identified. 

2. Conversely, the constraints from the other domains have to be integrated into 
the syntax of the language. 

3. The language evaluation mechanism (e.g. reduction or resolution) has to be 
extended by gathering constraints from the other domains. 

4. Finally one needs to carefully define the interface functions tell, and proj _^ 
of the new language solver. 

4-1 A Functional Logic Language as Constraint Solver 

The introduction of constraints into the rules of a functional logic language yields 
constraint functional logic programming. We follow our four step process. Recall 
that the basic syntactic construct is 

f{ti, ...,tn)^t where G 
where G is a set of constraints, including constraints from other domains. Moreover, 
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all constraints in G are homogeneous, that is, are built from the signature of one 
solver, including equalities ti =j:c of the functional logic language. 

(1) Identifying language constraints. Functional logic languages are based on equal- 
ities between terms. In order to state precisely what this means, we have to look 
more closely into the semantic models of these languages, cf. e.g. (|Manna 19741 
IWinskel 19931 [Broy et al. 1987| ). It has to be ensured that the operational semantics 
induced by our cooperating solvers is compatible with the mathematical semantics 
of the language under consideration. 

Recall that the semantic value of a term t in the model V is denoted by fi^v', when 
V is obvious from the context, we omit it and just write We are dealing with 
partial functions; according to the traditional convention we write "_L" (pronounced 
"bottom") to express partiality: |t| = _L means: t has no proper semantic value. 
We note in passing that there are two kinds of partiality, both of which can be 
subsumed under the element _L. One is nontermination of evaluations, the other is 
the lack of matching rules. For example, if there is no rule for X/0 - independent 
of the responsible solver - then we have ft/Ql = -L. The following discussion is 
exemplified with nontermination but it applies to both cases. 

Example 4.1. Consider the following superficial example over the natural numbers 
with constructors and s . (To ease reading we write s without parentheses.) 

f(0,Y) ^0 

f(sX,Y) ^f(X,f(sX,Y)) 

We consider a functional logic solver CSj^jr working in cooperation with others and 
we use again the notation from Example 13.11 to illustrate the snapshots from the 
evaluation. The formalisation of the interface functions for CSy^^ will be given and 
explained in more detail subsequently. 

Start from the constraint Z =j^c f (0, f (s 0, s 0)) in the pool. 



Z=^£f(0,f(sO,sO)) 


true 


true 


true 



In a call-by-name semantics we first reduce the outermost f using the first rule of 
the program. This immediately yields the result: Z =jf£ 0. Semantically this means 
[Z] = [f(0,f(sO,sO))l,,„ = lOl. 

In a call-by-value semantics we first reduce the innermost f using the second rule: 
Z =y^c f (0, f (0, f (s 0, s 0))). As one can immediately see, this reduction process 
will never terminate, that is, there will always be an equation Z ~j^c ti in the 
pool (with longer and longer right-hand sides ti). Semantically this means |Z] = 
|f(0,f(sO,sO))lcb„ = ±. < 

What does this mean for the introduction of variables? Recall that we need 
auxiliary variables for the homogeneity of the constraints for different solvers, i. e. 
we need to flatten constraints and terms. To see the pertinent problems, we modify 



18 



Petra Hofstedt and Peter Pepper 



the above example by introducing several auxiliary variables. Moreover, we add a 
further function g. 

f(0,Y) ^0 

f (sX, Y) f (X,W) where W =jr£ f (sX, Y) 
g(X) v^fhere f (sX, sX) =:f£ 



Let us first consider the operational semantics. We start from 



Z =^£ g(0) 


true 


true 


true 


After the first two steps this leads to the following situation: 


Z =rc 0, f (0, W) =rc 0, W f (s 0, 


sO) 




true 


true 


true 


In the next steps we may propagate Z —j^c and evaluate the two calls of f : 


W=^£f(0,W'), W =^£f(sO,sO) 


z = 


true 


true 


This may continue into the following configuration: 




=^c f(sO,sO) 






z = 0, w = 0, w = 0, ... 


true 


true 



This process will obviously continue forever, creating more and more auxiliary vari- 
ables w(J'. 

Let us compare this w. r.t. the original (not flattened) definition of the function 
f in Example 14.11 and the two kinds of mathematical semantics that we consider 
here. 

• Under call-by-value semantics, the result is [[Z| = |g(0)] = -L. 

• Under call-by-name semantics the result is |Z] = |g(0)] — |0|. 

Note that the auxiliary variables W, W', ... do not appear at all in the solution 
space of the mathematical semantics, since they are only internal artefacts of the 
computation process. 

Coming back to the operational semantics, we can only look up the value of Z in 
the store, when the computation is finished, that is, when the pool is empty. In the 
above example this will never happen; therefore we will never be able to extract 
the value Z = from the store. This means that Z has no value, i.e. |Z]] = _L. 
In other words: Without further precautions, the introduction of variables is only 
compatible with call-by-value semantics. 

How could we implement call-by-name semantics and still allow the introduction 
of variables? A simple solution consists of the introduction of a dependency relation 
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between variables. In our example, W' would depend on W, because it occurs in 
the term on the right-hand side of W. As soon as the pertinent rule would reduce 
W =jF£ f (0, W') to W ~j^c 0, the dependent variable W' would be eliminated from the 
pool. Moreover, the order of evaluation would have to follow the dependencies. 

As can be seen from this sketch, our method of handling hybrid constraints by 
flattening is more naturally related to call-by-value semantics, but with a little effort 
other semantic principles such as call-by-name can be accommodated as well. 

We note in passing that these considerations do not only apply to functional logic 
solvers, but to all kinds of solvers. Consider for example an arithmetic solver with 
the rule * X = 0. If we multiply the term g(0) from the above example by we 
obtain from Z = 0*g(0) the two constraints Z = 0*Xi, Xi =:fc g(0), which leads to 
Z = 0, Xi =:f£ g(0). Again, the differences between call-by-name and call-by-value 
can be captured by introducing a dependency of the variable Xi on Z. 

Remark on strict equality. From a semantic point of view it is unsatisfactory that we 
express undefinedness only operationally by the fact that the pool does not become 
empty. In a denotational setting, one would prefer to represent this situation also 
as _L. This brings strict equality into the game. 

In discussions about mathematical semantics there are usually two kinds of equal- 
ity: Under strong equality we have e.g. (_L _L) = true and (_L —x> 3) = false. 
And strict equality has the property Jti = ^2! =v -L if [^il =v -L or =x> -L- 
Strong equality obeys the laws of classical two-valued logic, but it is in general not 
decidable. Strict equality is a "normal" operator in the language but the semantics 
leads to all problems of three-valued logic. Neither equality is "better" than the 
other, they just serve different purposes. 

Call-by-value semantics evidently conforms nicely to strict equality. In our above 
example we have [[Z] = |g(0)] = p(sO,sO)] = ... = ±. Therefore every pool 
contains some equality of the kind [W^*^ = f (s 0, s 0)] and thus [W^*^ = _L]), which - 
under strict equality - is _L. Finally, we must consider conjunctions as strict such 
that the whole configuration is _L. This exactly reflects the fact that our computation 
does not terminate.^ The overall system remains semantically consistent, since a 
"wrong" equation such as Z = is in conjunction with _L and therefore does no 
harm. As a matter of fact, the overall configuration just moves in each step from 
one representation of the value _L to another representation of the value _L. 

The same considerations apply to call-by-name semantics. Here we have the sit- 
uation that e.g. [f(0,_L)] = 0. Therefore an equality like f(0,W) = 0, where both 
terms are different from _L, has the same truth value under both kinds of equality. 
However, if we encounter a function that is nonterminating even under call-by-name 
semantics, then we need again the strict equality in order to represent the overall 
nontermination by _L. 

The fact that the operational semantics requires additional means such as depen- 
dencies among variables is independent of the kind of equality. If one considers the 

^ The formal disjunctions that reflect the various branches of the evaluation need a different 
semantic treatment in order to accommodate the inherent nondeterminism. 
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above example, the computation is consistent, since it simply keeps adding valid 
equalities of the kind w'*) = to the store. All we need is a mechanism to stop it 
from doing this forever. 

(2) Extending the language by constraints of other domains. The syntax of the 
language also contains the constraints from the other domains (occurring in the part 
. . . where G of the rules). Therefore they are also part of the language constraints. 

To get a clean separation of concerns we also have to flatten hybrid terms from 
different domains. Suppose, for example, that we had given the third rule of our 
program in the hybrid form 

rc(par(Rl,R2)) ^ Z where l/rc(Rl) + l/rc(R2) =a 1/Z 
Then we would need to put this into the separated form 

rc(par(Rl,R2)) ^ Z where 1/X+ 1/Y =^ 1/Z, X =^£ rc(Rl), Y =^£ rc(R2) 

(3) Extending the language evaluation mechanism by gathering constraints. Func- 
tional logic languages are based on narrowing. Therefore we consider this evaluation 
mechanism as constraint solver CSj^jr. But in addition to performing the narrowing 
steps, the solver must also collect constraints from other domains (occurring in the 
part . . . where G) . 

The basic concept of a narrowing step with constraints can be described as follows: 
Let e be an equation with a distinguished non-variable subterm t, that is, e[t] with 
t ^ X. Let (I ^ r where G) be a rule from the program such that a = m,gu{t,l) 
unifies the subterm t with the left-hand side / of the rule. Then the narrowing step 
yields the new equation fT(e[r]) together with the rewritten constraint cr(G'), we 
write: e[t] ^„ {a{e[r]),a{G)). 

The extensive discussion of the previous pages has shown the various possibilities 
for choosing evaluation strategies and their impacts on the semantics. 

(4.) Defining the interface functions tellj^c o-^d proj j7jr_,jj of the particular language 
solver. This final step has to integrate the effects of narrowing and constraint col- 
lection with the other solvers. 

Propagation. Figure |S1 illustrates how the interface function telljrjr is used to simu- 
late a narrowing step with constraints, and Figure gives the formal definition of 
the pertinent requirements. To ease the presentation we suppose that all functional 
logic equalities are in the form Y =j^c t with variable Y and term t. This can always 
be achieved with the help of auxiliary variables. 

Like all solvers, CS'jC-^ propagates constraints to its store Cjc-^ thereby checking 
the satisfiability of Cjf£ in conjunction with the new constraints. Therefore the 
function telljr^ incorporates the principle of narrowing. 

In the light of the preceding discussion on flattening we assume that all con- 
straints which get into the pool (either as part of the initial problem to solve or 
as results of propagations or projections) are decomposed with the help of auxil- 
iary variables such that all subterms of the form f{ti, . . . ,tn), where / is a defined 
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Fig. 5. Application of the interface function tellj^c (see also Figure EJ 

function, are extracted. The definition of telljr,r therefore only needs to consider 
narrowing steps on outermost terms. The distinction between call-by-value and 
call-by-name must therefore be based on the aforementioned dependency relation 
among variables. 

We have to distinguish two kinds of constraints Y —rc t (see Figure (H)): 

1^ When the term t still contains defined functions, a narrowing step is applied 
as part of telljr^. This is only reflected by a change of the constraint pool. The store 
does not change in this case. Note that due to the flattening t contains exactly one 
defined function /, and this function is the outermost symbol in t. Moreover, since 
the substitution (p defined in Figure IHl only contains constructor terms, t = (j>{t) 
retains this property. 

(0) When the term t is a constructor term then the constraint Y =jf£ t is added 
to the store if possible. Thereby, the satisfiability test is realised by the parallel 
composition "f of substitutions. 

This integration of the narrowing into the propagation sometimes leads to earlier 
bindings of variables and thus to a faster recognition of unsuccessful computations. 
The price to be paid is that the solver CSj^^ is amalgamated into the function 
telljr^ - and with it all its problems. 

Example 4.2. To elucidate the interface definition we use our running example 
from Sect. IXTI In Step (2) of this example we applied the only matching rule 

rc(par(Rl,R2)) ^ Z where 1/X+ 1/Y =^ 1/Z, X=^£rc(Rl), Y =^£ rc(R2) 

to the initial configuration. We split the equation in the pool into two equations 
using an auxiliary variable such that the pool reads: 

Zi =.F£ rc(par(RA,RB)), Zi =^£ 200 

We pick the first term and apply tell^c as described in Figure El Note that we 
have the special situation, where the store C^c = (/> is still empty such that t — 
(^(rc(par(RA,RB))) = rc(par(RA, RB)). 

The narrowing step for the term with (a new instance of) the rule unifies the 
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tellTc- Let P be a functional logic program with constraints, let C^c = (jihe the current 
constraint store of CSj^c- (Recall that the constraint store Crc is nothing but a substi- 
tution 4> from variables to constructor terms, which is written in the form of equations 
and thus can be treated like constraints.) Let c = {Y =tc t) be the constraint to be 
propagated. Let i = (j){t). 

Finally, we use the following notion: A rule p = {Ip ^ rp where Gp) applies to t, if for 
t ^ X there is a unifier ap = mgu{t, Ip). 

We need to distinguish the following cases 

1. Let t contain defined functions; that is, t is of the form /(. . .) with / being the only 
defined function (due to the maximal flattening). If the set Pc C P of applicable 
rules is nonempty, then 

tellrc{c,CTc) = {true, Crc, \/pepMp ^ =^'C '^vi^p)) ^ '^p(G'p))). 

2. Let t be a constructor term, i.e. t £ T{A,X:fc)- 

(a) If {{Y = t} T C:fc) / 0, then 
tellj^c{c,Cj^c) = {true, {Y = t} 1 C^c ,true). 

(b) If {{Y = t} T C:fc) = 0, then 
tellrc{c,CTc) = {false,CTC, false). 

Fig. 6. Interface function telljr^ 



subterm rc(par(RA, RB)) - which happens to be the full term - with the left-hand 
side rc(par(Rl, R2)) of the rule. Since this matching exists, we have Case Q of 
FigureEl The resulting most general unifier is the substitution cr = {Rl = RA, R2 = 
RB}. Applied to the rule this substitution yields the instantiated right-hand side Z 
and constraints 1/X + 1/Y =^ 1/Z, X =jr^ rc(RA), Y =jr^ rc(RB). This is put back 
into the pool: 

Rl =jrc RA, R2 =jrc RB, Zi ^jrc Z, 1/X + 1/Y 1/Z, X =jrc rc(RA), 
Y ^jrc rc(RB), Zi 200 

If there is more than one applicable rule, we get a number of newly built constraint 
pools. 

Applying telljr^ to the two constraints Rl —j^c and R2 =jr£ RB leads to 
Case 2. (a) of Figure E| As a result the store Cy^c then contains these constraints (a 
substitution). The remaining constraints in the pool are as follows: 

Zi ^jrc Z, Zi ^jrc 200, 1/X + 1/Y =A 1/Z, X ^jrc rc(RA), Y ^jr^ rc(RB). 

Note, that Example 13 . II displays simplified forms for brevity. < 



Projection. Since the constraint store Cjf£ only contains substitutions, the projec- 
tion is trivial. It generates equality constraints representing them. For example, 
in Step (7) the constraint Z =^ 200 is transferred from Cjr£ to the pool using 

The specification of the function proj;p^_,^ is given in Figured (Note, that the 
equalities in the result are indexed v to express the fact that they now belong 
to the domain of the solver CSi,.) 
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proj -p^^^: The projection of a store Crc = w. r.t. a constraint system and a set 
of variables X C Xjf/: H makes the substitutions for x £ X explicit: 

L true otherwise. 



Fig. 7. Interface function proj jr^^,,^, v £ L 



Completeness and other aspects. Since the interface functions tell^c and proj jr^r^jj 
of our functional logic language solver fulfil the requirements given in Sect.|2| the 
soundness and completeness results of the cooperation framework hold for the inte- 
gration of a functional logic language - however, only relative to the completeness 
of the narrowing strategy encoded within tellyrjr. 

It is well known that narrowing is in principle a complete and sound method 
for theories presented by confluent and terminating rewrite systems. But in con- 
nection with functional logic languages and in particular in the presence of ex- 
tra variables the issue of completeness becomes more intricate. This problem has 
been investigated by several authors, among others ( |Middeldorp and Hamoen 1994| 
ISuzuki et al. 1995 : Hanu,s_1995) . These papers discuss slightly different syntactic 
criteria, which guarantee that certain narrowing strategies (e. g. lazy or needed 
narrowing) are sound and complete. 

Evidently, these criteria carry over to the narrowing strategy that we embed into 
our function tellj^c- For lack of space we cannot go into details here. Suffice it to 
say that, for example, our program rule 

rc(par(Rl,R2)) ^ Z v^fhere 1/X+ 1/Y =^ 1/Z, X =^£ rc(Rl), Y =^£ rc(R2) 

contains the three extra variables X, Y and Z and is in the class 3-CTRS of ( |Middeldorp and Hamoen 1994| ). 
But the syntactic form also meets the requirements of being orthogonal^ properly 
oriented and right-stable (|Suzuki et al. 1995|l . which guarantees that the program 
is level-confluent. (These conditions essentially state that the variables are in a nice 
left-to-right order.) 

As a matter of fact, the rule is also constructor-based and functional in the 
sense of (jHanus 1995|l . since the variables Rl and R2 in the guarding constraints 
occur in the left-hand side and the variable Z of the right-hand side is deflned by 
the guarding constraints. This also entails the completeness of lazy and needed 
narrowing. But Hanus imposes a further requirement: the equality ^j^c has to be 
strict (which allows to consider it as an equality iY = t) —j^c true). Since we only 
put substitutions with constructor terms into the store C;r£, this works in our 
approach as well. (This is similar to the language CURRY (|Hanus et al. 2003)1 .1 

However, there is one further issue! The above quoted requirements refer to the 
functional logic equalities in the guard G. But our rules have a more general form: 

/(ti, . . . ,i„) r where ci, . . . ,c™,ui =jr^ vi,...,Uk =tc Vk 

Only the equalities Ui =j^c Vi (with Ui being a constructor term, possibly only a 
variable) belong to the functional logic solver. The Cj are constraints from other 
domains. 
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This raises the question: How do these constraints ci , . . . , Cm from the other 
domains fit into the picture? Let us consider our standard example 

rc(par(Rl,R2)) ^ Z where 1/X+ 1/Y =^ 1/Z, X=^£rc(Rl), Y =^£ rc(R2) 

Without the first constraint, the variable Z would not occur in the guard and thus 
the rule would not even be 3-CTRS (and thus no completeness results could be 
given at all). On the other hand, all constraints Ci do not contain any of the defined 
functions and therefore do not participate in any kind of narrowing strategy. So, 
from the point of view of narrowing, a variable like Z can be treated like a constant. 

If one of the other solvers finds a solution, e. g. Z = 200 in our example, then the 
corresponding substitution is put into the store Cj^c- This way the associated value 
is guaranteed to be a ground constructor term and thus does not interfere with the 
narrowing strategies. 

This illustrates again the - evident - fact that the completeness of the overall 
system, and thus also of its narrowing part, depends on the completeness of all 
participating solvers. 

4-2 A Logic Language as Constraint Solver 

The integration of a logic language into the system of cooperating solvers yields a 
constraint logic programming language. Since this is actually simpler than the case 
of functional logic languages, we only sketch it here briefly. 

(1 & 2) Identifying language constraints and extending the language by constraints 
of other domains. It is widely accepted that logic programming can be interpreted 
as constraint programming over the Herbrand universe. The appropriate constraint 
solving mechanism CSc is resolution. 

The goals according to a given constraint logic program P are the natural con- 
straints of a logic language solver. Furthermore, the set Consc of constraints of this 
solver must contain equality constraints Y —c t between variables and terms to 
represent substitutions.® 

We extend the syntax of the language by constraints of other constraint systems 
which yields the typical CLP syntax, cf. e.g. IjJaffar and Lassez 1987|l . Thus, the 
set Consc must furthermore include all constraints of the incorporated solver(s). 

(3 & 4) Extending the language evaluation mechanism by gathering constraints and 
defining the interface functions of the particular language solver. For the integration 
of CSc into the system the interface functions telle and proj must be defined. 
Step (3), i.e. gathering constraints during resolution, is realised by the extension 
of the resolution step from atoms to the whole body including the constraints of 
other domains. 

^ Not all CLP systems support equalities on the syntactical level. Rather they only generate them 
internally in the solver. In our system, they are explicitly visible. 
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telle- Let P be a constraint logic program, let Cc = (f) he the current store of CSc- 

1. Let R — p{t\,...,tm) be the constraint (goal) which is to be propagated. Let 
R = (j}{R)- We use the following notion: A rule p — {Qp :- rhsp) applies to R, if 
there is a unifier ap — mgu{R, Qp). 

(a) If the set Pr C P of applicable rules is nonempty, then 
tellc{R,Cc) = {true, Cc, ^ p^Pj^{<^p ^ (^p{rhsp))). 

(b) If there is no applicable rule in P, then 
tellc{R,Cc) = {false,Cc, false). 

2. Let c — {Y —c t) be the constraint which is to be propagated. 

(a) If {{Y = t} T C*/;) / 0, then 
tellc{c,Cc) = [true, {Y = t} ^ Cc ,true). 

(b) If ({F = t} T Cc) = 0, then 
tellc{c,Cc) = if alse,Cc, false). 



Fig. 8. Interface function telle 



Propagation. The propagation function telle emulates resolution steps (including 
gathering constraints). Its formal definition is given in Figure |H1 Case l.(a) repre- 



sents a resolution step on a goal i? as a successful propagation, where for every 
applicable rule we get a newly created constraint pool and, thus, a new instanti- 



ation of the architecture. If there is no applicable rule for a goal, i.e. Case l.(b) 



the propagation fails (in contrast to the functional logic solver considered before, 
undefinedness of a predicate is regarded as failure here) . 

Similar to the definition of tellj^e the remaining cases describe the propagation 
of equality constraints by parallel composition of substitutions (Casel^J. 



Projection. As before, the projection function provides constraints representing the 
substitution from the store which has been computed during resolution. The def- 
inition of the projection function proj ^^^^ is the same as for the functional logic 
language solver given in Figure where the index JF£ is replaced by C to denote 
the origin of the projection. 

Since the interface functions telle and proj e—n, fulfil the requirements given in 
Sect. 13 the soundness and completeness results of the cooperation framework hold 
for the integration of a logic language. 



5 Conclusion and Related Work 

This paper describes a general approach for the integration of declarative languages 
and constraint systems. This essentially means to treat their evaluation mechanisms 
together with programs as constraint solvers. This is done in four general steps: 

1. Identifying language constraints, 

2. Extending the language by constraints of other domains, 

3. Extending the language evaluation mechanism by gathering constraints, 

4. Defining the interface functions of the particular language solver. 



26 



Petra Hofstedt and Peter Pepper 



The most important aspect of our approach is that the overaU system for coop- 
erating solvers allows the handling of hybrid constraints over different domains. 

Gains and perspectives. Our general framework for cooperating solvers provides 
mechanisms for the definition of cooperation strategies. Similar to CLP(X) IjJaffar and Lassez 1987|l 
and CFLP(X) ( |L6pez-Fraguas 1992J , which are covered by our approach, the frame- 
work can thus be instantiated by three parameters: a strategy definition S, a set 
X of constraint systems and a host language 3^. In this way, our approach enables 
the building of constraint languages customised for a given set of requirements for 
a comfortable modelling and the solution of many problems. 

For example, if one needs a convenient language to express search problems with 
special constraints over finite and/or further domains, the user chooses a logic lan- 
guage and according constraint systems. For problems which allow or require a 
more deterministic modelling one may decide to build a constraint language based 
on a functional or functional logic language. In a similar way one can imagine to 
combine a database language with constraints IjKanellakis et al. 1995|l or a partic- 
ular special-purpose language or system, such as an expert system, a geographical 
information system, or a planning system. Of course, the user is responsible for a 
sound specification of the language constraints and the definition of the interface 
functions. 

The meta-solver system meta-S l|Frank et al. 2003bl IFrank et al. 2003ajl imple- 
ments our ideas. Even though meta-S provides programming constructs for its 
integration into other applications, which may even be imperative languages, the 
true integration of imperative languages according to our approach is an open ques- 
tion and a topic of future research. The main reason is that declarative languages 
abstract from real-world issues such as time and state while imperative languages 
are time-dependent which complicates their integration also for our approach. 

The choice of an appropriate cooperation strategy plays an important role for 
the efficiency of the cooperating system l|Frank al. 2p03al. 

The definition of solver cooperation strategies is also very interesting in the case 
of language solvers. This will allow for example to switch from depth-first search 
to breadth-first search or an evaluation mechanism based on the Andorra principle 
l|Costa et al. 199ll I Warren 1988|l using a logic language without reimplemcnting 
the evaluation mechanisms. The system meta-S already offers predefined strategy 
patterns for these search strategies which can be refined by problem-dependent 
knowledge or user knowledge about the program. 

If the user is able to define cooperation strategies for the solvers and the lan- 
guage(s) or to refine them on the base of predefined strategy patterns (as given in 
our implementation), she/he can also employ problem-dependent knowledge and 
user knowledge, e. g. about the termination of particular predicates, to guide the 
computation. 

First results l|Frank et al. 2004|l on the integration of language solvers into the 
meta-solver framework META-S according to the described approach confirm our 
theoretical considerations. 
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Finally, the approach opens a further interesting perspective: A simple approach 
for the combination of different languages consists of the definition of an explicit 
interface and providing language constructs for initialising subcomputations in the 
particular languages. In this way one reaches a loose coupling and interaction of 
programs written in different languages. 

Our cooperation framework bases on a similar idea: It provides a meta mecha- 
nism which takes care of the strategy of the cooperating solvers and provides the 
constraint pool for maintaining and managing common data and constraints. Be- 
sides this the main concept is the uniform solver interface which allows to integrate 
declarative languages as solvers as shown above. Using this interface it is not only 
possible to integrate constraint solvers and language evaluation mechanisms but 
also to integrate language evaluation mechanisms among each other by appropri- 
ate interface definitions. This finally yields a language interaction according to the 
above sketched interface model. 



Related Work. Lopez-Fraguas (19921 considered a general scheme CFLP(X) for 
constraint functional logic programming. The scheme is based on lazy functional 
logic languages and allows beside conditions constraints in the guards of the rules. 
Using our cooperation approach, we achieve a covering of the CFLP(X) and CLP(X) 
(Jaffar and Lassez 1987) approaches. In (Hortala-Gonzal ez et al. 19 97) and l|Fernandez et al. 2003|l . 
extending CFLP(X), functional logic programming is integrated with real arith- 
metic and finite domain constraints respectively. The lazy functional logic languages 



toy(7?.) and toy{!F'D) are the respective implementations. Lux (2001 J integrates 
linear constraints over real numbers into the functional logic language CURRY in a 
similar way. 



OPEN CFLP by Kobayashi et al. (2003 1 combines a functional logic host language 
with collaborating equational solvers which may be distributed in an open environ- 
ment. It provides the user with a declarative strategy definition for the cooperat- 
ing solvers basing upon a set of basic operators. However, the strategy language of 
META-S gives finer control over the individual collaboration steps because of its well 
considered solver interface on the one hand and its structural pattern-matching and 
constraint rewriting facilities which provide a finer and more intuitive control for 
strategy definition on the other hand. 

While our approach pursues the idea to integrate languages into a system of coop- 
erating solvers the approaches ( |L6pez-Fraguas 1992| IHortala-Gonzalez et al. 19971 
IFernandez et al. 20031 [Kobayashi et al. 2003| ILux 200 l]l come from the opposite 
point of view and extend the functional logic program evaluation by constraint 
evaluation. 

In contrast to the other approaches our framework allows the integration of sev- 
eral constraint systems. The user can integrate desired domains and solvers which 
satisfy the interface requirements as discussed in Sect. 13 The opportunity to in- 
tegrate different host languages and constraint systems also distinguishes our ap- 
proach from other existing systems of cooperating solvers (for example ( |Hong 1994| 
[Monfroy 1996|IR,ueher 1995|l ) that usually have one fixed host language (a logic lan- 
guage). 
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Furthermore both, the above mentioned languages and the cooperative systems, 
mainly have a fixed order of evaluation of constraints and functional expressions 
resp. In contrast, an integration according to our ideas using the meta-S system 
allows the user to either define its own strategies or to refine existing strategy 
patterns in a simple way. The usefulness of different cooperation strategies has been 
proven for usual solvers (e. g. on arithmetic, see IjFrank et al. 2003^)1 ). As well, first 
results for the integration of a logic language into meta-S confirm their usefulness 
for language solvers IjFrank et al. 2004jl . 

OZ (Miiller et al. 199 5ll supports (constraint) logic, functional and object-oriented 
programming styles within one (as well fixed) language. The computation in OZ is 
based on the concept of computation spaces HSchulte 2002|l which consist of a con- 
straint store containing only basic constraints and propagators (for more complex 
constraints) manipulating them. Similar to our framework, computation spaces can 
be used to describe solver cooperations and search strategies. However, this relies 
on all solvers sharing the same store format and hence is not satisfying for the main 
goal of our approach, i. e. the cooperation of black box solvers independent of their 
implementation. 
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